According to my experiments, it is not necessary to disable systemd-udev.service in order to fix bsc#1246133.

So I will add a commit removing that service from the list. We want to release a new version of Agama (and its corresponding live image) next week, so I prefer to keep changes to the minimum necessary.

So I will add a commit removing that service from the list.

Turns out disabling only lvm2-monitor.service and lvm-activate-system.service was not enough. So I will run some more experiments.

Ok. Let me make a summary.

First of all, the third line would be systemd-udevd.service instead of systemd-udev.service. But it doesn't work anyways.

I used this pull request as a base to do several unsuccessful experiments:

1. Disabling lvm2-monitor.service and lvm-activate-system.service. It didn't work because systemd-udevd.service still fiddles with lvm.
2. Disabling lvm2-monitor.service, lvm-activate-system.service and systemd-udevd.service. It didn't work because systemd-udevd.service was triggered by systemd-udevd-kernel.socket and systemd-udevd-control.socket. And then it fiddled with lvm.
3. Disabling lvm2-monitor.service, lvm-activate-system.service, systemd-udevd.service, systemd-udevd-kernel.socket and systemd-udevd-control.socket. It didn't work. The behavior was identical to the previous case.
4. Masking (not only disabling) lvm2-monitor.service, lvm-activate-system.service and systemd-udevd.service. It didn't work because the system was not even able to configure the network.

I'm running a final experiment before giving up and leaving this for the next tester.

Looks like I finally found the option that works: masking (not disabling) lvm2-monitor.service and lvm-activate-system.service.

I'm pretty sure we don't need them because libstorage-ng will take care of activating LVM. I'm also pretty sure that disabling them is not enough.

So I modified this pull request according to those findings.